IBIS Macromodel Task Group

Meeting date: 14 March 2023

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Aurora Systems:             * Dian Yang
Cadence Design Systems:     * Ambrish Varma
                              Jared James
Google:                       Hanfeng Wang
                              GaWon Kim
Intel:                      * Michael Mirmak
                            * Kinger Cai
                              Chi-te Chen
                              Alaeddin Aydiner
Keysight Technologies:        Fangyi Rao
                              Majid Ahadi Dolatsara
                              Stephen Slater
                            * Ming Yan
                              Rui Yang
Luminous Computing            David Banas
Marvell                       Steve Parker
Mathworks (SiSoft):           Walter Katz
                              Mike LaBonte
Micron Technology:          * Randy Wolff
                              Justin Butterfield
Missouri S&T                  Chulsoon Hwang
                              Yifan Ding
Rivos                         Yansheng Wang
SAE ITC                       Michael McNair
Siemens EDA (Mentor):       * Arpad Muranyi
Teraspeed Labs:             * Bob Ross
Waymo:                        Zhiping Yang
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- Randy said the Quality task group had an update on the AMI root name checking
  topic, time permitting (see below).

-------------
Review of ARs:

Stephen: Socialize the SPIM proposal/BIRD with experts in the field and gather
         their feedback.
		 - In progress.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the March 7th
meeting.  Kinger moved to approve the minutes.  Dian seconded the motion.
There were no objections.

--------------
New Discussion:

PSIJ Sensitivity BIRD draft:
Kinger said he had received no new feedback on draft8.  He reviewed the changes
contained in draft8 (see minutes from March 7th, 2023).

Kinger and Arpad noted that references to [Device SPIM Group] in draft8 were
premature and should be removed, as the SPIM BIRD had not yet been approved.
Kinger said he would remove references to [Device SPIM Group], but he and Arpad
said this minor editorial change was not sufficient to require a new draft to be
sent out.

Randy asked whether we need a way to define which signal pins are affected by
the PSIJ.  How would the user know what buffers are affected by the jitter
distribution that is computed with the help of these new keywords?

Kinger said this proposal is holistically looking at the final jitter
distribution that would be applied to the final Rx eye diagram.  If it were for
a clock forwarded architecture such as DDR5, then it would include the
cumulative effects on the data channel signal and the clock signals, for
example.  The jitter computed using the [PSIJ Sensitivity] data and the noise
spectral density of the power rail(s) would be applied to the final eye.

Randy noted that we have the [Clock Pins] keyword in IBIS.  While it's not
related to this topic directly, it establishes a precedent for having a list of
pins that are somehow related.  Randy wondered whether we need an additional
keyword with this proposal to define the list of signal pins that are affected
by the jitter computed using the [PSIJ Sensitivity] information.  Randy and
Arpad then discussed whether the rail names from [PSIJ Voltage List] could be
mapped back to individual buffers via the [Pin Mapping] keyword, but they said
we need to think about this carefully.

Randy asked whether this jitter is something the tool would add in during post
processing or whether it would be a jitter input to an AMI model.  Kinger said
the tool could perform a noiseless SI simulation and then add this total jitter
in as a post processing step.  Arpad said this was an interesting question.  He
noted that AMI defines Reserved jitter parameters that are applied to the Tx
stimulus waveform.  If the jitter contributions affecting the blocks included
in the Tx AMI model were applied to the stimulus waveform, then the behavior of
the models might be affected (filter adaptations, etc.), and spectral filtering
by the channel would occur, and the overall results might be quite different
than those obtained by adding everything in via post processing of the Rx final
eye.

Ambrish asked what distributions were being considered here Gaussian, random,
etc.  Kinger said this BIRD does not determine the distribution.  The user or
tool define a simulation that determines the power noise on the rail(s).  The
[PSIJ Sensitivity] information then allows the tool to map the noise spectral
density to a jitter distribution.  Kinger said determining the noise profile may
be complicated.  There may be many power modes to consider, sleeping, waking up,
etc., and you would want to capture all of the possible activities in your noise
profile.  Arpad said this proposal aims to combine a noiseless signal simulation
with a signalless power simulation.  Kinger agreed.

Ambrish asked whether this proposal was defining a new methodology.  Arpad said
he agreed with comments from Walter in a recent meeting that the specification
should define the data that is made available, but it should not define flows.
Ambrish noted that some flows are defined, AMI itself, for example.  Wei-hsing
said that if two simulators come up with very different results using the same
data, then questions will come back to this group.

Dian returned to Randy's original question and asked whether we need to add
information about which signal pins are impacted by the jitter.  Kinger said he
didn't think so.  He referred to Arpad and Randy's previous comments about the
possibility of mapping back to signal pins using [PSIJ Voltage List] rail names
and the [Pin Mapping] keyword.  Randy suggested that we think about this more.

Dian presented an HDMI scenario.  He said it has a clock signal and data signals,
and perhaps certain power rails only affect the clock and others only affect the
data.  Kinger said eventually you want to get the final eye at the Rx, and all
the clock and data jitter variations would be included.  He said this proposal
doesn't necessarily want to separate out individual contributions and handle
data and clock eye diagrams individually.

Quality Task Group question/update, BUG 227 - AMI root name check:
Randy reported that the Quality task group had decided not to address BUG227 at
the present time.  They do not want to hold up the development of ibischk7.2.
In order for the parser to confirm that the executable model returned the same
root name found in the .ami file, the parser would have to call AMI_Init().  At
present, there is no way to guarantee that the parser could come up with valid
input to AMI_Init() for any given model.  There are many cases in which models'
AMI_Init() functions will fail or crash with bad input data.  Randy noted that
IBIS 7.2 had at least clarified the requirement that the root name returned by
the model must match that in the .ami file.  However, there is nothing the
parser can do to test or enforce that requirement at the current time.

Arpad suggested that one solution might be to add a new AMI Reserved parameter.
If the model advertised this parameter, and the tool passed in the right value,
the model would operate in a type of test mode and only return the root name.
In this scenario, AMI_Init() would not look at all the other inputs.

Michael asked whether having [AMI Test Load] and [AMI Test Data] would solve the
problem.  He said that if a they were defined, then the parser would be sure
that it could provide valid input when calling AMI_Init().  Michael said he
would have a proposal for [AMI Test Load] and [AMI Test Data] within the next
few months.

Arpad said that a simple Reserved parameter might be easier for the model maker
and might encourage faster adoption.  He then noted that his proposal might not
be so simple if we ever plan to support multiple root names (multiple parameter
trees) in one .ami file.  Would the Reserved parameter have to return a list of
the valid root names?  Bob said we don't support different root names in a .ami
file.  Michael and Arpad said we might consider doing so in the future and using
them as a sort of model selector.

Ambrish said it would be more helpful if the model simply complained when it
didn't like the root name it received in AMI_parameters_in.  Arpad asked whether
this needed further discussion.  Michael recommended that we defer discussion
until he has an [AMI Test Load]/[AMI Test Data] proposal ready.  He said that we
need that data anyway, and it will then make this parser check possible.

- Curtis: Motion to adjourn.
- Kinger: Second.
- Arpad: Thank you all for joining.

-------------
Next meeting: 21 March 2023 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
